Overview
Sometimes its necessary to migrate the server from one server machine to another. This document will explain the steps involved and that the client should expect post migration.
Why Migrate?
Migration requires some commitment of time and effort for the business and tech team. During the migration process there is also an expected down time. So the reasons for migration should be very clear. Some good reasons are:
- Poor Host Provider Infrastructure - One may further ask how do we know if its the application or the host provider? Typically, if the site is down most of the times then the site itself is not running and this ususally can be atrributed to the host provider.
- Slow Server - This can be either due to the application/platform itself or host provider. Speed tests can determine the cause. Some possible reasons for slow speed are:
- Insufficient CPU or RAM
- Heavy images on the webpage that are not using a CDN
Both the above are different types of infrastructure issues. The latter can be catered to by optimizing resources and using a CDN over an above your existing host solution. The former results in the page itself rendering slow, which requires a Host upgrade or migration.
- Poor host provider Support - Your website maybe up most of the time, but when there is an issue it stays down for long. If your site is a busy site or one that should be up when you need it, then this is unaceptable and you need to get better support from your host provider.
- Costs - You have multiple servers for different things, and wish to consolidate multiple applications, sites, blogs under one roof and single command and control. However this type of migration should invest a lot of time in Prep since multiple parties maybe involved. This can get complex and do not attempt if all your vendors are not aligned.
Preparing for Migration
Before you Migrate the following preparations need to be made:
- Plan a date range for Migration. A typical migration should allow atleast 2 weeks, this may include even half a day or a day of down time for applications that rely only on 1 server. Though in practice the downtime can be just a couple of hours, but business should be ready for a day atleast.
- Make a list of what all items need to be backed up and communicate that to the team performing the migration. Typically these are Database, Files & Images, Scripts, backups, folder permissions.
- Make a note of space occupied by existing server and usage. The server being migrated to should be able to handle that and more in the future.
- Check with business if emails will be impacted. If Email migration is not in scope, the new server may not support the mails even if mail accounts ar ere-created. Busines should be avised to download all their mails via their mail client. In the case the mail server is on a different email server like GMail then there is no worry.
- DNS Records - Sub domains, MX records etc should be backedup so that the new server also supports them (if any configured at the server level). Ideally these are configured at the Domain level and not the hosting level, so it should not "ideally" be a concern.
Infrastructure Purchase
- Purchase Host server - Typically this is a VPS on Linux. See BlueHost VPS India or Linode. Bluehost is in India and also offers CPanel. Linode is more suited to companies that have in house IT for complete management of site and email.
- Purchase SSL certificate - If your site has security needs (like e-commerce), you will additionally need to purchase an SSL certificate. One can purchase them from sites like Go Daddy. Purchase one for minimum 3 years.
Once purchase is done, be sure to inform the developer about access to the accounts. Additionally one has to wait to a day for the host server to setup the raw server before the development team can begin work.
Migration Process
- Clone existing server to new Server. The cone server will though not assume Master settings. For example: it will connect to the test payment gateway instead of the real one (if possible) etc so no real transactions are made. If the server is VPS we (dev team) have to do additional steps:
- Verify access and credentials to Billing panel, Server and any other VPS admin panels like CPanel (if purchased)
- Verify Server setup by hostprovider - Like OS, Location, any add ons liek CPanel
- Setup OS with latest patches
- Setup Database, Mail Server accounts, FTP Server accounts, Apache, Tomcat etc.
Ensure you save access useful links, details of various softwares installed in a single document for the project.
- Create database schema, folder structure for project
- (Optional Optimization) clean out any non used images, files from old server to reduce Disk and transfer footprint
- rsync from old server to new server (content and maybe site itself if no new version is to be uploaded)
If rsync is not allowed, then client should FTP previously uploaded, catalog and content files to their local disk.
Also run ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/ /' -e 's/-/|/' or run tree command to get a structure.
So when the client uploads back, its possible to verify the uploaded structure Vs original structure should anything go wrong.
- export database from old server to new server
- Ensure environment settings are communicated into the project properties files. Folder locations etc
- Upload and deploy site to new server
- Configure Tomcat, Apache to run with website
- (Optional & additional) Migrate emails from old server to new server
- Setup SSL and redirects (If site uses SSL)
- Setup third party integrations like payment gateway
- Tech team internally validates the site and ensures its working fine.
- Once tech team is satisfied, it asks Business to test the site and admin. Business should be agressive in testing at this stage because testing on a live site is risky.
- Once business is satisfied, the following steps are performed:
- Drain users from old server - For high traffic websites, wait for usage to be minial so that Number of users impacted is absolutely low (if any). Typically the best time is mid night local time.
- Existing Server is shut down for a few hours / until new server is up. This is done because we cannot allow users to come to both the sites, it may leave some data out
- Ensure the new server is operational and assumes the role of the Master. (Configurations upgraded to actual production values)
- Take latest update of Database, files from old server and update new server (To synch any updates that happened while the migration was in progress)
- Domain DNS record is made to point to new server or the Domain Name is transferred to the new Server. This can take upto a Day
- Ask business to test new server first thing in the morning. If there are issues at this point, it may result in further down time as one cannot afford to go back to the old server. Issues should be resolved on priority and ensure the new server is Live and working.
- If business are using a proxy then esnure DNS is flushed properly so that their machines or network are not using the old Cached IP Address. This is a common problem and can cause users to experience failures even though the new site is up and absolutely fine.
Client Checklist
Post migration the client should test the following among many things
- Check you are able to access the website admin panel
- Check in your admin images are appearing
- Check you can uplaod files via FTP and you know which folders to upload to. The folder structure may change and you may not be familiar. Check with the developer if you have trouble
- Do the following tests on your site. The following is not the complete set of tests you can perform but the bare minimal to know there is no major issue or disruption in getting your site to work normal on the internet.
- Update content - and test buttons Save, Preview, Publish, Revert
- Upload images via CMS and use it on a page
- Update Products via Admin (if you have a catalog based site)
- Update Products via ETL (if you have a catalog based site)
- Make an Order and reject it at last stage (if you have a e-commerce based site)
- Make an Order and go ahead with payment (if you have a e-commerce based site)
- Check SALE, NEW work (if you have a e-commerce based site)
- Ensure you are getting all emails as an administrator and as a customer (check your SPAM folder incase you did not get an email). The home page of admin shows the email addresses used for administrator etc.
- Do a sanity check on all your pages
Troubleshooting
- Ensure you take a screenshot of the problem you are facing and send it to the migration team
- On your command prompt run ping <domain name>, and comunicate the result. Example: ping mydomain.com
On Windows:
On Mac:
- Always clear your browser cache and try to work from a fresh instance of the Browser in Private or Incognito Mode
Testing site, when Domain is not set
Your domain name is the name you refer your site to with. Example www.mywebsite.com. However while migration, because your new server is untested or incomplete we cannot risk pointing your domain name to the new server early. For this reason your server maybe running on a raw public IP address. However there is a way to fool your local machine into believing the new server is running on your domain and testing it as if it were live on the internet.
You have to goto your hosts file (see section where it says location of this file), and add an entry like this:
SERVER_IP_ADDRESS mywebsite.com
SERVER_IP_ADDRESS www.mywebsite.com
For example, it should look like:
67.199.146.25 mywebsite.com
67.199.146.25 www.mywebsite.com
...Make sure that there is a space between the IP and the URL! Otherwise, the rule will not work.
For windows and macs please see the location of this file below.
- Windows : Open the file @ location C:\WINDOWS\system32\drivers\etc\hosts
- Mac : You may either type Terminal on the Spotlight, or by going into Applications -> Utilities -> Terminal and then open file using "sudo nano /private/etc/hosts" (without quotes)
